HPAVC

home *** CD-ROM | disk | FTP | other *** search

/ HPAVC / HPAVC CD-ROM.iso / pc / FAQSYS18.ZIP / FAQS.DAT / SERPORT.18 / text0000.txt < prev next >

Wrap

Text File | 1995-12-12 | 45.5 KB | 1,012 lines

Date of release: 22 Feb 1995 Release 18 This is a summary on serial communication using the TTY protocol. It contains information on the TTY protocol and hardware and software implemen- tations for IBM PCs which has been derived from National Semiconductor data sheets and practical experience of the author and his supporters. Starting with release 5, some information on modems has been added. If you want to contribute to this file in any way, please email me (probably just reply to this posting). My email address is: chbl@stud.uni-sb.de or chris@phil.uni-sb.de. See the end for details. It's the seventeenth publication of this file. Some errors have been corrected and some information has been added (which has surely brought other errors with it, see Murphy's Law). [] brackets often indicate comments to sneaked material; copied lines are indented. I've made great efforts to always mention who's to be credited. Please tell me if you find something that you've written that's not correctly associated with your name. This compilation of information is (C) Copyright 1993 - 1995 by Christian Blum; all rights reserved. This file is not to be reproduced commercially, not even partially, without written permission. You are allowed to use it in any other way you like. I don't want any (monetary) profit being drawn out of it (neither by me nor by others! I don't mind if you have a look or two at it at work though... :-). Please feel free to provide this file to others for free or at your own expenses. Changes since the last publication ================================== Used more proper interrupt acknowledging in the examples (namely the method I suggested some chapters before :) in order to avoid lock-ups on MCA computers. (Thanks, Erik) Added some info on the auto flow-control feature of the TL16C550C. (Thanks, naddy) What I'm doing ============== I'm no longer very much into DOS (though I still make some money with it :), so don't expect me reading all the groups regularly that I'm posting this to. What others are doing ===================== There is a file available from ftp.phil.uni-sb.de, pub/staff/chris called The_Serial_Port.more05 that contains an article by Bob Niland covering serial communication under Windows. It is regularly posted to comp.sys.ibm.pc.hardware.comm and other groups; if you obtain it from there it's probably more up to date. No more "Automatic File Delivery" (AFD) service =============================================== The automatic mail reply service I've mentioned in earlier releases of this file is still available, but I won't do anything to keep it alive from now on. Please obtain the files via anonymous ftp from ftp.phil.uni-sb.de (134.96.80.220), pub/staff/chris. If you don't have access to ftp, try using an ftp to email gateway (ftpmail@decwrl.dec.com or bitftp@pucc.princeton.edu, and probably a lot more; put 'help' in the body to obtain instructions). If everything fails, write to me. Acknowledgements (quite a bunch of people by now...) ================ The following persons have contributed (directly or indirectly :-) to this summary by providing information or making suggestions/reporting errors. Tell me if your name is missing. Madis Kaal <mast@anubis.kbfi.ee> Steve Poulsen <stevep@ims.com> Scott C. Sadow <NS16550A@mycro.UUCP> Dan Norstedt <?> Alan J. Brumbaugh <brumba@maize.rtsg.mot.com> Mike Surikov <surikov@adonis.iasnet.com> Varol Kaptan <E66964%trmetu.bitnet@relay.EU.net> Richard F. Drushel <rfd@po.CWRU.Edu> John A. Limpert <johnl@n3dmc.svr.md.us> Brent Beach <ub359@freenet.victoria.bc.ca> Torbjoern (sp?) Lindgren <tl@etek.chalmers.se> Stephen Warner <ee_d316@dcs.kingston.ac.uk> Kristian Koehntopp <kris@black.toppoint.de> Angelo Haritsis <ah@doc.ic.ac.uk> Jim Graham <jim@n5ial.mythical.com> Ralf Brown <ralf@cs.cmu.edu> Alfred Arnold <zam036@zam112.zam.kfa-juelich.de> Andrew M. Langmead <aml@world.std.com> Richard Clayton <richard@locomotive.com> Christof Baumgaertner <baumg@rhrk.uni-kl.de> Goran Bostrom <GORAN@infovox.se> Brian Mork <bmork@opus-ovh.spk.wa.us> Richard Steven Walz <rstevew@armory.com> Scott David Daniels <daniels@cse.ogi.edu> Brian Onn <Brian.Onn@Canada.Sun.COM> Erik Suurmaa <erik@lerdeil.ee> Terence Edwards <Terence@tedwards.demon.co.uk> Christian 'naddy' Weisgerber <naddy@mips.pfalz.de> Introduction ============ One of the most universal parts of the PC (except for the CPU, of course :-) is its serial port. You can connect a mouse, a modem, a printer, a plotter, another PC, dongles :) ... But its usage (both software and hardware) is one of the best-kept secrets for most users, besides that it is not difficult to understand how to connect (not plug in) devices to it and how to program it. Regard this file as a manual for the serial port of your PC for both hardware and software. Historical summary ------------------ In early days of telecommunication, errand-boys and optical signals (flags, lights, clouds of smoke) were the only methods of transmitting information across long distances. With increasing requirements on speed and growing amount of information, more practical methods were developed. One milestone was the first wire-bound transmission on May 24th, 1844 ("What hath God wrought", using the famous Morse alphabet). Well, technology improved a bit, and soon there were machines that could be used like typewriters, except that you typed not only on your own sheet of paper but also on somebody elses. The only thing that has changed on the step from the teletype to your PC regarding serial communications is speed. The TTY (teletyping) protocol ----------------------------- Definition: A protocol is a clear description of the LOGICAL method of transmitting information. This does NOT include physical realization. There is a difference between bits per second and baud (named after J. M. E. Baudot, one of those guys who gave a real push to teletyping): 'baud' means 'state changes of the line per second' while 'bits per second' ... well, bits per second means bits per second. You may find this a bit weird because the numbers are often the same; there's only a difference if the line has more than two states. Since this is not the case with the RS-232C (EIA-232) port of your PC, most people don't differentiate between 'baud' and 'bits per second', while I do. For your convenience, I've replaced baud with bps even in copied material without special notice. Where you still find baud, it should read bps in most cases (I didn't change labels in source codes, pin names in data sheet information etc.). To illustrate the difference I give you some figures: 2400 bps at 8n1 carry 1920 bits of information per second, and modems send them at 600 baud thru' the phone wires using eight line states, while 1200 bps at 7e1 carry 840 bits of information per second that modems send at 600 baud using four different line states. I know it's confusing... that's why I quote this from a letter I received from Brent Beach. He explained it more clearly than I did (I've added some information): Perhaps a small diagram might help, showing the relationship among the players: [bps] [baud] CPU Data Serial Phone Bus -- bytes --> Port -- bits --> Modem -- tones --> line -- | | CPU Data Serial | Bus <-- bytes -- Port <-- bits -- Modem <-- tones ---------- (1) (2) (3) The serial port accepts bytes from the CPU data bus and passes bits to the modem. In doing this, the serial port can add or delete bits, depending on the coding scheme in use. At (1) we are concerned with bytes per second. At (2) we are concerned with bits per second, and at (3) it's baud. We distinguish because the number of bits at (2) need not be equal to the number of bits (that is, bytes times 8) at (1), and the number of state changes at (3) is not necessarily the same as the number of bits before. Bits can be stripped going from (1) to (2): the serial port may transmit only 6 or 7 of the 8 bits in the byte. Bits can be added going from (1) to (2): the serial port can add a parity bit and stop bits. From (2) to (3), bits may be clustered to groups that are transmitted using different encoding schemes like 'Frequency Shift Keying' or 'Quadrature Amplitude Modulation', to name some. You can determine the transfer rate in bytes per second depending on the serial port speed and the coding system. For example, 8n1: 1 start bit + 8 data bits + 1 stop bit = 10 bits per word. At 2400 bps, this is 240 bytes/characters per second. 2400 bps are normally transmitted using QAM ('Quadrature Amplitude Modulation') where 4 bits are clustered, and hence encoded to 600 baud. 7e1: 1 start bit, 7 data bits, 1 even parity bit, 1 stop bit = 10 bits per word. At 1200 bps, this is 120 bytes/characters per second. 1200 bps are encoded using DPSK ('Differential Phase Shift Keying', two bits are clustered), and this results again in 600 baud. Now let's leave modems for a while and have a look at the serial port itself. The TTY protocol uses two different line states called 'mark' and 'space'. (For the sake of clearness I name the line states 'high' (voltage) for positive and 'low' (voltage) for negative voltages). If no data is transmitted, the line is in its quiescent 'low' ('mark') state or in the 'break' state ('high'). Data looks like space +---+ +---+ +---+ high '0' +12V | | | | | | mark ----------+ +-------+ +---+ +------- low '1' -12V (1) --------(2)-------- (3) (1) start bit (2) data bits (3) stop bit(s) Steve Walz reported that in most (all?) books these kind of diagrams are drewn the other way round (I just copied what I saw on the oscilloscope) and that he'd use the labels 'high' and 'low' the other way round, corresponding to the signals on the TTL level (a matter of taste I guess); here is what he told me: In American texts, we will expect to see the data frame for serial transfer of all kinds represented, despite the method of transfer (RS-232C, RS-422, and optical even), as being an interruption of a normally HI state, and we expect to see the diagram you drew in the older release 8, but with the labelling corrected as I have indicated: mark ----------+ +-------+ +---+ +------- high '1' -12V logical 1 | S | 1 1 | 0 | 1 | 0 | Stop space +---+ +---+ +---+ low '0' +12V (1) --------(2)---------(3) (1) start bit (2) data bits (3) stop bit(s) Thus transmitting the bit stream 01011, which is LSB first, MSB last. Indeed it seems to us that a zero SHOULD be the quiescent state, and the one an active state, but the first teletypes used a current loop to continuously monitor the state of the line, and thus current flow was regarded as a 1 and it is "MARK" -ing time, and a signal then left a "SPACE" in the graph of current flow designating a zero. Thus the bits following the start bit at level zero were true to their bit values, and a 11111 in 5 bit baudot looked like this, using three dashes per bit: mark ------ ------------------------ 1 HI +5V TTL -12V RS-232C space --- 0 LO 0V TTL +12V RS-232C s 1 1 1 1 1 stop and the baudot 10101 would appear thus: mark ------ --- --- ------------ 1 HI +5V TTL -12V RS-232C space --- --- --- 0 LO 0V TTL +12V RS-232C s 1 0 1 0 1 stop and the baudot 01010 would appear thus: mark ------ --- --- --------- 1 HI +5V TTL -12V RS-232C space ------ --- --- 0 LO 0V TTL +12V RS-232C s 0 1 0 1 0 stop and finally baudot 00000 would appear: mark ------ --------- 1 HI +5V TTL -12V RS-232C space ------------------ 0 LO 0V TTL +12V RS-232C s 0 0 0 0 0 stop Now I know that we don't send five bit baudot over RS-232C now, but I wasn't about to try 8 bits, if you don't mind! :) I know that people get confused about the proper way to draw these, since we use inverted voltages to send them via RS-232C interface now, but they are still called logical "1" and "mark" when it is really -12 Volts DC, and it is called "0" and "space" when it is +12 Volts. And logical one or "mark" corresponds to +5 Volts, while logical zero is "space" and corresponds to 0 Volts. It is this way both within the parallel bus of the computer or the transmit output of a UART/USART, with the exception that this data frame is terminated by remaining logic "1" or "mark" as a stop bit and preface to the next data frame. Both transmitter (TX) and receiver (RX) use the same data rate (measured in bps, see above), which is the reciprocal value of the smallest time interval between two changes of the line state. TX and RX know about the number of data bits (probably with a parity bit added), and both know about the (minimum!) size of the stop step (called the stop bit or the stop bits, depending on the size of the stop step; normally 1, 1.5 or 2 times the size of a data bit). Data is transmitted bit-synchronously and word-asynchronously, which means that the size of the bits, the length of the words etc.pp. is clearly defined while the time between two words is undefined. The start bit indicates the beginning of a new data word (this means one single character). It is used to synchronize transmitter and receiver and is always a logical '0' (so the line goes 'high' or 'space'). Data is transmitted LSB to MSB, which means that the least significant bit (LSB, Bit 0) is transmitted first with 4 to 7 bits of data following, resulting in 5 to 8 bits of data. A logical '0' is transmitted by the 'space' state of the line (+12V), a logical '1' by 'mark' (-12V). A parity bit can be added to the data bits to allow error detection. There are two (well, actually five) kinds of parity: odd and even (plus none, mark and space). Odd parity means that the number of 'low' or 'mark' steps in the data word (including an optional parity bit, but not the framing bits) is always odd, so the parity bit is set accordingly (I don't have to explain 'even' parity, must I?). It is also possible to set the parity bit to a fixed state or to omit it. See Registers section for details on types of parity. The stop bit does not indicate the end of the word (as it could be derived >from its name); it rather separates two consecutive words by putting the line into the quiescent state for a minimum time (that means the stop bit is a logical '1' or 'mark') in order for the next start bit to be clearly visible. The framing protocol is usually described by a sequence of numbers and letters, eg. 8n1 means 1 start bit (always the same, thus omitted), 8 bits of data, no parity bit, 1 stop bit. 7e2 would indicate 7 bits of data, even parity, 2 stop bits (but I've never seen this one...). The usual thing is 8n1 or 7e1. Your PC is capable of serial transmission at up to 115,200 bps (step size of 8.68 microseconds!). Typical rates are 300 bps, 1200 bps, 2400 bps and 9600 bps, with 19200 bps, 38400 bps and 57600 bps becoming more and more popular with high speed modems. Note that some serial ports have difficulties with high speeds! I've seen PS/2's failing to operate at more than 38400 bps! How come that IBM machines are often the least IBM compatible? :-) This is what John A. Limpert told me about teletypes: Real (mechanical) teletypes used 1 start bit, 5 data bits and 1.42 stop bits. Support for 1.5 stop bits in UARTs was a compromise to make the UART timing simpler. Normal speeds were 60 WPM (word per minute), 66 WPM, 75 WPM and 100 WPM. A word was defined as 6.1 characters. The odd stop bit size was a result of the mechanical nature of the machine. It was the time that the printer needed to finish the current character and get ready for the next character. Most teletypes used a 60 mA loop with a 130 V battery. 20 mA loops and lower battery voltages became common when 8 level ASCII teletypes were introduced. The typical ASCII teletype ran at 110 bps with 2 stop bits (11 bits per character). It's surely more exact than what I wrote in previous releases. I've just got to add that at least in Germany 50 bps was a familiar speed. And I think the lower battery voltage he's talking about was 24 volts. The physical transmission ------------------------- Teletypes used a closed-loop line with a quiescent current of 20ma and a space current of 0ma (typically), which allows to detect a 'broken line' (hence the name of the 'break' flag, see the Registers section). The RS-232C port of your PC uses voltages rather than currents to indicate logical states: 'mark'/'low' is signaled by -3v to -15v (typically -12V) and represents a logical '1', 'space'/'high' is signaled by +3v to +15v (typically +12V) and represents a logical '0'. The typical output impedance of the serial port of a PC is 2 kiloohms (resulting in about 5ma @ 10v), the typical input impedance is about 4.3 kiloohms, so there should be a maximum fan-out of 5 (5 inputs can be connected to 1 output). Please don't rely on this, it may differ from PC to PC. Three lines (RX, TX & ground) are at least needed to make up a bidirectional connection. Q. Why does my PC have a 25pin/9pin connector if there are only 3 lines needed? A. There are several status lines that are only used with modems etc. See the Hardware section and the Registers section of this file. Q. How can I easily connect two PCs by a three-wire lead? A. Connect RX1 to TX2 and vice versa, GND1 to GND2. In addition to this, connect RTS to CTS & DCD and connect DTR to DSR at each end (modem software often relies on that). See the hardware section for further details. Please be aware that at 115,200 bps (ie. ca. 115 kHz, but we need the harmonics up to at least 806 kHz) lines can no longer be regarded as 'ideal' transmission lines. They are low-pass filters and tend to reflect and mutilate the signals, but some ten meters of twisted wire should always be OK (I use 3m of screened audio cable for file transfer purposes, and it works fine. Not that other kinds of wire wouldn't do; I took what I found). See a good book on transmission lines if you're interested in why long lines can be a problem. This has been posted to comp.os.msdos.programmer by Andrew M. Langmead: The RS-232C spec. has an official limit of 50 ft for RS-232C cables. Realistically they can be much longer. The book "Managing UUCP and Usenet" by O'Reilly and Associates has a table that they credit to "Technical Aspects of Data Communications", by McNamara (Digital Press, 1992). It lists the maximum distances for an RS-232C connection. Baud Rate | max distance | max distance | shielded cable | unshielded cable ---------------------------------------------------------- 110 | 5000ft | 3000ft 300 | 5000ft | 3000ft 1200 | 3000ft | 3000ft 2400 | 1000ft | 500ft 4800 | 1000ft | 250ft 9600 | 250ft | 250ft Please note that "baud" is correct in this case, because we're speaking of the transmission line itself. This is what Torbjoern (sp?) Lindgren told me: I have successfully transmitted at 115,200 with over 30m long cables! And it wasn't especially good wires. I had some old telecables with 20 individual wires, and used 7 of them for transfer, and left the others unconnected. I don't remember the exact length, but I know it was something over 30m, and it probably was closer to 40m than 30m. The unused lines probably shielded the lines from each other or something like that. The computers used were two PC-compatibles with off-the-shelf com-ports. Nothing fancy. Note that some serial ports are more critical with mutilated signals than others, so you just have to try and find out yourself what works. Hardware ======== The connectors -------------- PCs have 9pin/25pin male SUB-D connectors. The pin layout is as follows (seen from outside your PC): 1 13 1 5 _______________________________ _______________ \ . . . . . . . . . . . . . / \ . . . . . / \ . . . . . . . . . . . . / \ . . . . / --------------------------- ----------- 14 25 6 9 Name (V24) 25pin 9pin Dir Full name Remarks -------------------------------------------------------------------------- TxD 2 3 o Transmit Data Data RxD 3 2 i Receive Data Data RTS 4 7 o Request To Send Handshaking CTS 5 8 i Clear To Send Handshaking DTR 20 4 o Data Terminal Ready Status DSR 6 6 i Data Set Ready Status RI 22 9 i Ring Indicator Status DCD 8 1 i Data Carrier Detect Status GND 7 5 - Signal ground Reference level - 1 - - Protective ground Don't use this one as signal ground! The most important lines are RxD, TxD, and GND. Others are used with modems, printers and plotters to indicate internal states. '1' ('mark', 'low') means -3v to -15v, '0' ('space', 'high') means +3v to +15v. On status lines, 'high' is the active state: status lines go to the positive voltage level to signal events. The lines are: RxD, TxD: These lines carry the data; 1 is transmitted as 'mark' (what I call 'low') and 0 is transmitted as 'space' ('high'). RTS, CTS: Are used by the PC and the modem/printer/whatsoever (further on referred to as the data set, or DCE) to start/stop a communication. The PC sets RTS to 'high', and the data set responds with CTS 'high'. (always in this order). If the data set wants to stop/interrupt the communication (eg. imminent buffer overflow), it drops CTS to 'low'; the PC uses RTS to control the data flow. DTR, DSR: Are used to establish a connection at the very beginning, ie. the PC and the data set 'shake hands' first to assure they are both present. The PC sets DTR to 'high', and the data set answers with DSR 'high'. Modems often indicate hang-up by resetting DSR to 'low' (and sometimes are hung up by dropping DTR). (These six lines plus GND are often referred to as '7 wire'-connection or 'hand shake'-connection.) DCD: The modem uses this line to indicate that it has detected the carrier of the modem on the other side of the phone line. The signal is rarely used by the software. RI: The modem uses this line to signal that 'the phone rings' (even if there is neither a bell fitted to your modem nor a phone connected :-). GND: The 'signal ground', ie. the reference level for all signals. Protective ground: This line is connected to the power ground of the serial adapter. It should not be used as a signal ground, and it MUST NOT be connected to GND (even if your DMM [Digital MultiMeter] shows up an ohmic connection!). Connect this line to the screen of the lead (if there is one). Connecting protective ground on both sides makes sure that no large currents flow thru' GND in case of an insulation defect on one side (hence the name). Technical data (typical values for PCs): Signal level: -10.5v/+11v Short circuit current: 6.8ma Output impedance: ca 2 kiloohms (non-linear!) Input impedance: ca 4.3 kiloohms (non-linear!) Other asynchronous hardware than RS-232C ---------------------------------------- There are several other standards that use the same chipset and protocol as RS-232C. RS-422 and the more robust (but compatible) version RS-485 (to name some) use two wires for every signal. The transmitters can usually be disabled and enabled by software, which makes it possible to use such equipment in a bus system (RX and TX part share the same lines). Despite >from the possibility to enable and disable the receiver/transmitter section of the port, they are fully compatible to existing RS-232C software if a compatible chipset is used. It's not possible to connect eg. RS-232C to RS-485 without an appropriate interface. Connecting devices (or computers) ------------------ When you connect a data set or DCE (eg. a modem), use this connection: GND1 to GND2 RxD1 to RxD2 TxD1 to TxD2 DTR1 to DTR2 DSR1 to DSR2 RTS1 to RTS2 CTS1 to CTS2 RI1 to RI2 DCD1 to DCD2 In other words, simply connect each pin of the first plug with the corresponding pin of the other. This can easily be done using a 25-wire ribbon cable and two crimp connectors. When you connect another computer (or any other DTE, like a terminal), this is the wiring you need (it is called a "null modem" connection): GND1 to GND2 RxD1 to TxD2 TxD1 to RxD2 DTR1 to DSR2 DSR1 to DTR2 RTS1 to CTS2 CTS1 to RTS2 If software wants it, connect DCD1 to CTS1 and DCD2 to CTS2. If hardware handshaking is not needed, you can omit the status lines. Connect: GND1 to GND2 RxD1 to TxD2 TxD1 to RxD2 Additionally, connect (if software needs it): RTS1 to CTS1 & DCD1 RTS2 to CTS2 & DCD2 DTR1 to DSR1 DTR2 to DSR2 You won't need long wires for these! :-) Remember: the names DTR, DSR, CTS & RTS refer to the lines as seen from the DTE (your PC). This means that for your data set DTR & RTS are incoming signals and DSR & CTS are outputs! Modems, printers, plotters etc. are connected 1:1, ie. pin x to pin x. Base addresses & interrupts --------------------------- Normally, the following list is correct for your PC; note however that if the BIOS can't find a port, it won't leave spaces in its port table, so if there is no UART at 0x3E8, the port at 0x2E8 will be called COM3 by DOS. Compare the section on logical vs. phyical names. Port Name Base address Int # Int level (IRQ) COM1 0x3F8 0xC 4 COM2 0x2F8 0xB 3 COM3 0x3E8 0xC 4 COM4 0x2E8 0xB 3 In your programs, you should refer to the table in the BIOS data segment. This is an excerpt from Ralf Brown's interrupt list (the actual author of this section is Robin Walker): Format of BIOS Data Segment at segment 40h: Offset Size Description 00h WORD Base I/O address of 1st serial I/O port, zero if none 02h WORD Base I/O address of 2nd serial I/O port, zero if none 04h WORD Base I/O address of 3rd serial I/O port, zero if none 06h WORD Base I/O address of 4th serial I/O port, zero if none Note: Above fields filled in turn by POST as it finds serial ports. POST never leaves gaps. DOS and BIOS serial device numbers may be redefined by re-assigning these fields. Please note that this table is not the bible and that the BIOS is not an evangelist (and I'm rather sceptical anyway :-). Your BIOS might not tell you the pure truth; if you get a zero it does not necessarily mean that there are no more serial ports available. Your programs should nevertheless have a look at the usual places for comm ports. See the "Programming" section for an example program that checks if a UART is installed at a given base address. Compare the "logical vs. physical names" section below. Another good idea is writing a small program that's then run in the AUTOEXEC.BAT and that fills the empty fields in the table with the correct values. My Award BIOS fails to recognize my fourth port at 0x2E8, so I typed a few bytes (14 altogether) in the debugger that write 0x2E8 to 0040:0006 and wrote them to a .COM file called in the AUTOEXEC.BAT. Also see the Programming section for a routine that detects the interrupt level/number that a UART uses. It's not a good idea to hard-code level 4 and 3; make it at least user configurable. See the chapter "Multi-Port Serial Adapters" for further information. Logical vs. physical ports -------------------------- DOS users (like card manufacturers) tend to confuse logical and physical names. COM1, COM2, etc. are _logical_ names for the serial ports 0, 1, etc. found by the BIOS during POST (Power-On Self Test). The BIOS searches at four different I/O addresses for UARTS: 0x3F8, 0x2F8, 0x3E8, 0x2E8, in exactly this order. Every UART found has an entry in the comm port table at segment 0x40, offset 0. The BIOS manages up to four different UARTs, because the table has no more than four spaces. To make the confusion complete, Microsoft decided that DOS users wouldn't be comfortable with counting from zero, so they numbered the logical names of the comm ports from 1 to 4. Thus COM1 is the first UART found by the BIOS during POST, COM2 the second, and so on. Usually COM1 has 0x3F8 as base addresses, COM2 0x2F8 and so on, but that's not necessarily the case. Please do not use the logical DOS names when you really mean physical addresses. It is _not_ possible to 'jumper a UART as COM3', at least not directly. The chipsets ------------ In PCs, serial communication is realized with a set of three chips (there are no further components needed! (I know of the need of address logic & interrupt logic ;-) )): a UART (Universal Asynchronous Receiver/Transmitter) and two line drivers. Normally, the 82450/16450/8250 does the 'brain work' while the 1488 and 1489 drive the lines (they are level shifting inverters; the 1488 drives the outputs). These chips are produced by many manufacturers; it's of no importance which letters are printed in front of the numbers (mostly NS for National Semiconductor). Don't regard the letters behind the number also (if it's not the 16550A or the 82C50A); they just indicate special features and packaging (Advanced, New, MILitary, bug fixes [see below] etc.) or classification. Letters in between the numbers (eg. 16C450) indicate technology (C=CMOS). You might have heard that it is possible to replace the 16450 by a 16550A to improve reliability and reduce software overhead. This is only useful if your software is able to use the FIFO (first in-first out) buffer feature. The chips are fully pin-compatible except for two pins that are not used by any serial adapter card known to the author: pin 24 (CSOUT, chip select out) and pin 29 (NC, no internal connection). With the 16550A, pin 24 is -TXRDY and pin 29 is -RXRDY, signals that aren't needed (except for DMA access - but not in the PC) and that even won't care if they are shorted to +5V or ground. Therefore it should always be possible to simply replace the 16450 by the 16550A - even if it's not always useful due to lacking software capabilities. IT IS DEFINITELY NOT NECESSARY FOR COMMUNICATION AT UP TO LOUSY 9600 BPS! These rates can easily be handled by any CPU, and the interrupt-driven communication won't slow down the computer substantially. But if you want to use high-speed transfer with or without using the interrupt features (ie. by 'polling'), or multitasking, or multiple channels 'firing' at the same time, or disk I/O during transmission, it is recommendable to use the 16550A in order to make transmission more reliable if your software supports it (see excursion some pages below). There *are* differences between the 16550A, 16550AF, and 16550AFN. The 16550AF has one more timing parameter (t_RXI) specified that's concerned with the -RXRDY pin and that's of no importance in the PC. And the 16550AFN is the only one still believed to be free of bugs (see below). So the best choice for your PC is 16550AFN, but you are well off with the 16550AN, too. [Info from a posting of Jim Graham.] Don't worry about the missing 'A' if you have chips named xxx16550 which are not from National Semiconductor (eg. UM16550). As long as the first example in the 'Programming' section tells you that it is a 16550A, everything is fine. I've never heard of non-NS 16550s with the FIFO bug (see below). How to detect which chip is used -------------------------------- This is really not difficult. The 8250 normally has no scratch register (see data sheet info below), the 16450/82450 has no FIFO, the 16550 has no working FIFO :-) and the 16550A performs alright. See the Programming section for an example program that detects which one is used in your PC. Note that there _are_ versions of the 8250 that _do_ have a scratch register! It's rather impossible to distinguish them from the 16450, but then it's not necessary either... I know of the SAB 82C50 from Siemens and the UM8250B (from UMC, a taiwanese company with a globe symbol; thanks, Alfred, for helping me out with that). You won't find 8250s in fast computers however, because their bus timing is too slow. Data sheet information ---------------------- Some hardware information taken from the data sheet of National Semiconductor (shortened and commented): Pin description of the 16450 (16550A) [Dual-In-Line package]: +-----+ +-----+ D0 -| 1 +-+ 40|- VCC D1 -| 2 39|- -RI D2 -| 3 38|- -DCD D3 -| 4 37|- -DSR D4 -| 5 36|- -CTS D5 -| 6 35|- MR D6 -| 7 34|- -OUT1 D7 -| 8 33|- -DTR RCLK -| 9 32|- -RTS SIN -| 10 31|- -OUT2 SOUT -| 11 30|- INTR CS0 -| 12 29|- NC (-RXRDY) CS1 -| 13 28|- A0 -CS2 -| 14 27|- A1 -BAUDOUT -| 15 26|- A2 XIN -| 16 25|- -ADS XOUT -| 17 24|- CSOUT (-TXRDY) -WR -| 18 23|- DDIS WR -| 19 22|- RD VSS -| 20 21|- -RD +-------------+ Note: The status signals are negated compared to the port! If you write a '1' to the appropriate register bit, the pin goes 'low' (to ground level). On its way to the port, the signal is inverted again; this means that the status line at the port goes 'high' if you write a '1'. The same is true for inputs: you get a '1' from the register bit if the line at the port is 'high'. SIN and SOUT are inverted, too. (negative voltage at the port means +5v at the UART). A0, A1, A2, Register Select, Pins 26-28: Address signals connected to these 3 inputs select a UART register for the CPU to read from or to write to during data transfer. A table of registers and their addresses is shown below. Note that the state of the Divisor Latch Access Bit (DLAB), which is the most significant bit of the Line Control Register, affects the selection of certain UART registers. The DLAB must be set high by the system software to access the Baud Generator Divisor Latches. [I'm sorry, but it's called that way even if it's a bps rate generator... :-)]. 'x' means don't care. DLAB A2 A1 A0 Register 0 0 0 0 Receive Buffer (read) Transmitter Holding Reg. (write) 0 0 0 1 Interrupt Enable x 0 1 0 Interrupt Identification (read) x 0 1 0 FIFO Control (write) [undefined with the 16450. CB] x 0 1 1 Line Control x 1 0 0 Modem Control x 1 0 1 Line Status x 1 1 0 Modem Status x 1 1 1 Scratch [special use on some boards. CB] 1 0 0 0 Divisor Latch (LSB) 1 0 0 1 Divisor Latch (MSB) -ADS, Address Strobe, Pin 25: The positive edge of an active Address Strobe (-ADS) signal latches the Register Select (A0, A1, A2) and Chip Select (CS0, CS1, -CS2) signals. Note: An active -ADS input is required when Register Select and Chip Select signals are not stable for the duration of a read or write operation. If not required, tie the -ADS input permanently low. [As it is done in your PC. CB] -BAUDOUT, Baud Out, Pin 15: This is the 16x clock signal from the transmitter section of the UART. The clock rate is equal to the main reference oscillator frequency divided by the specified divisor in the Baud Generator Divisor Latches. The -BAUDOUT may also be used for the receiver section by tying this output to the RCLK input of the chip. [Yep, that's true for your PC. CB]. CS0, CS1, -CS2, Chip Select, Pins 12-14: When CS0 and CS1 are high and CS2 is low, the chip is selected. This enables communication between the UART and the CPU. -CTS, Clear To Send, Pin 36: When low, this indicates that the modem or data set is ready to exchange data. This signal can be tested by reading bit 4 of the MSR. Bit 4 is the complement of this signal, and Bit 0 is '1' if -CTS has changed state since the previous reading (bit0=1 generates an interrupt if the modem status interrupt has been enabled). D0-D7, Data Bus, Pins 1-8: Connected to the data bus of the CPU. -DCD, Data Carrier Detect, Pin 38: blah blah blah, can be tested by reading bit 7 / bit 3 of the MSR. Same text as -CTS. DDIS, Driver Disable, Pin 23: This goes low whenever the CPU is reading data from the UART. It can be used to control bus arbitrary logic. -DSR, Data Set Ready, Pin 37: blah, blah, blah, bit 5 / bit 1 of MSR. -DTR, Data Terminal Ready, Pin 33: can be set active low by programming bit 0 of the MCR '1'. Loop mode operation holds this signal in its inactive state. INTR, Interrupt, Pin 30: goes high when an interrupt is requested by the UART. Reset low by the MR. MR, Master Reset, Pin 35: Schmitt Trigger input, resets internal registers to their initial values (see below). -OUT1, Out 1, Pin 34: user-designated output, can be set low by programming bit 2 of the MCR '1' and vice versa. Loop mode operation holds this signal inactive high. [Not used in the PC. CB] -OUT2, Out 2, Pin 31: blah blah blah, bit 3, see above. [Used in your PC to connect the UART to the interrupt line of the slot when '1'. CB] RCLK, Receiver Clock, Pin 9: This input is the 16x bps rate clock for the receiver section of the chip. [Normally connected to -BAUDOUT, as in your PC. CB] RD, -RD, Read, Pins 22 and 21: When RD is high *or* -RD is low while the chip is selected, the CPU can read data from the UART. [One of these is normally tied. CB] -RI, Ring Indicator, Pin 39: blah blah blah, Bit 6 / Bit 2 of the MSR. [Bit 2 only indicates change from active low to inactive high! Curious, isn't it? CB] -RTS, Request To Send, Pin 32: blah blah blah, see DTR (Bit 1). SIN, Serial Input, Pin 10. SOUT, Serial Output, Pin 11. -RXRDY, -TXRDY: refer to NS data sheet. These pins are used for DMA channeling. Since they are not connected in your PC, I won't describe them here. VCC, Pin 40, +5v VSS, Pin 20, GND WR, -WR: same as RD, -RD for writing data. XIN, XOUT, Pins 16 and 17: Connect a crystal here (1.5k betw. xtal & pin 17) and pin 16 with a capacitor of approx. 20p to GND and other xtal conn. 40p to GND. Resistor of approx. 1meg parallel to xtal. Or use pin 16 as an input and pin 17 as an output for an external clock signal of up to 8 MHz. Absolute Maximum Ratings: Temperature under bias: 0 C to +70 C Storage Temperature: -65 C to 150 C All input or output voltages with respect to VSS: -0.5v to +7.0v Power dissipation: 1W Further electrical characteristics see the very good data sheet of NS. UART Reset Configuration Register/Signal Reset Control Reset State -------------------------------------------------------------------- IER MR 0000 0000 IIR MR 0000 0001 FCR MR 0000 0000 LCR MR 0000 0000 MCR MR 0000 0000 LSR MR 0110 0000 MSR MR xxxx 0000 (according to signals) SOUT MR high (neg. voltage at the port) INTR (RCVR errs) Read LSR/MR low INTR (data ready) Read RBR/MR low INTR (THRE) Rd IIR/Wr THR/MR low INTR (modem status) Read MSR/MR low -OUT2 MR high -RTS MR high -DTR MR high -OUT1 MR high RCVR FIFO MR/FCR1&FCR0/DFCR0 all bits low XMIT FIFO MR/FCR1&FCR0/DFCR0 all bits low Known problems with several chips --------------------------------- (From material Madis Kaal received from Dan Norstedt and stuff Erik Suurmaa sent me) 8250 and 8250-B: * These UARTs pulse the INT line after each interrupt cause has been serviced (which none of the others do). [Generates interrupt overhead. CB] * The start bit is about 1 us longer than it ought to be. [This shouldn't be a problem. CB] * 5 data bits and 1.5 stop bits doesn't work. * When a 1 is written to the bit 1 (Tx int enab) in the IER, a Tx interrupt is generated. This is an erroneous interrupt if the THRE bit is not set. [So don't set this bit as long as the THRE bit isn't set. CB] * The first valid Tx interrupt after the Tx interrupt is enabled is probably missed. Suggested workaround: 1) Wait for the THRE bit to become set. 2) Disable CPU interrupts. [?] 3) Write Tx interrupt enable to the IER. 4) Write Tx interrupt enable to the IER again. [Don't ask me why. I don't think it's necessary. CB] 5) Enable CPU interrupts. [?] * The TEMT (bit 6) doesn't work properly. * If both the Rx and Tx interrupts are enabled, and a Rx interrupt occurs, the IIR indication of the Tx interrupt may be lost. Suggested workarounds: 1) Test THRE bit in the Rx routine, and either set IER bit 1 or call the Tx routine directly if it is set. 2) Test the THRE bit instead of using the IIR for Tx. [If one of these chips vegetates in your PC, go get your solder iron heated... CB] 8250A, 82C50A, 16450 and 16C450: * (Same problem as above:) If both the Rx and Tx interrupts are enabled, and a Rx interrupt occurs, the IIR indication may be lost; Suggested workarounds: 1) Test THRE bit in the Rx routine, and either set IER bit 1 or call the Tx routine directly if it is set. 2) Test the THRE bit instead of using the IIR. 3) [Don't enable both interrupts at the same time. CB] 4) [Replace the chip by a 16550AFN; it has this bug fixed. CB] 16550 (without the A): * Rx FIFO bug: Sometimes the FIFO will get extra characters. [This seemed to be very embarrassing for NS; they've added a simple detection method for the 16550A (bit 6 of IIR). CB] 16550 AF * When the TX FIFO is enabled, a character loss can appear if the CPU writes a byte into the THR while the last one is still in the shift register (not completely sent). [This is documented by National Semiconductor; I've never experienced that, but that might be because I've never seen a 16550 AF :) CB] * Terence Edwards reports that his RS485 adapter with 16550 AF chips and a 16 MHz xtal gets parity bits wrong at 512 kbps; not very astonishing I'd say because the chip is only guaranteed to operate at 256kbps, with an 8 MHz xtal, and parity generators are rather slow circuits. No 16550 AFN bugs reported (yet?) [Same is true for the 16552, a two-in-one version of the 16550AFN, and the 16554, a quad-in-one version. CB] You might call this a bug, though: in FIFO mode, THRE (bit 5 or LSR) is cleared when there is at least one character in the Tx FIFO, not if the FIFO can't take any more bytes; that's rather absurd, but that's the way it is. A very solid method of handling the UART interrupts that avoids all possible int failures has been suggested by Richard Clayton, and I recommend it as well. Let your interrupt handler do the following: 1. Disarm the UART interrupts by masking them in the IMR of the ICU. 2. Send a specific or an unspecific EOI to the ICU (first slave, then master, if you're using channels above 7). 3. Enable CPU interrupts (STI) to allow high priority ints to be processed. 4. Read IIR and follow its contents until bit 0 is set. 5. Check if transmission is to be kicked (when XON received or if CTS goes high); if yes, call tx interrupt handler manually. 6. Disable CPU interrupts (CLI). 7. Rearm the UART interrupts by unmasking them in the IMR of the ICU. 8. Return from interrupt. This way you can arm all four UART ints at initialization time without having to worry about stuck interrupts. Start transmission by simply calling the tx interrupt handler after you've written characters to the tx fifo of your program. If you need details about programming the ICU, refer to Chris Hall's document about the 8259 that's available from my archive. [... continued ...] -- Chris Blum <chris@phil.uni-sb.de> http://www.phil.uni-sb.de/~chris/